Method and system for determining, contracting to exchange, and accounting for matched sets of offsetting cash flows

ABSTRACT

Among other embodiments, methods and systems are disclosed for determining one or more sets of structured cash flows corresponding to a graph having one or more nodes corresponding to one or more exchange definitions or swap transactions. The net present value of a structured cash flow may be substantially zero, and may correspond to a maximum notional amount, a maximum flow, or a minimum cut.

This application claims priority to U.S. provisional patent applicationSer. No. 60/152,702 filed Sep. 7, 1999, entitled METHOD AND SYSTEM FORDETERMINING, CONTRACTING TO EXCHANGE, AND ACCOUNTING FOR MATCHED SETS OFOFFSETTING CASH FLOWS, which is incorporated by reference.

FIELD

The present invention relates to the field of electronic systems forlocating counterparties and clearing markets for exchange of structuredcash flows.

BACKGROUND

It is frequently desirable for parties to exchange cash flow streamshaving different term structures or risk profiles but similar netpresent values. Three examples of such exchanges are known in thefinancial industry as interest rate swaps, currency swaps and commodityswaps.

In one common interest rate swap transaction, a first party agrees topay to a second party a fixed rate of interest for a certain period on agiven sum in exchange for receiving from the second party a floatingrate of interest on the same sum (the “notional amount”) for the sameperiod. Market practice is for one party to pay the other the net of thetwo interest payments on each payment date. Such a transaction is knownas a “fixed-for-floating” swap. In most cases, the notional amount neednot be exchanged.

In a common currency swap transaction, a first party exchanges a givensum in a first currency for the same sum in a second currency from asecond party. For a certain period, the second party pays a first rateof interest on the given sum in the first currency to the first party,and the first party pays a second rate of interest on the given sum inthe second currency to the second party. At the end of the period, thesum is re-exchanged at the original exchange rate. In practice, only thedifference in the amounts adjusted for exchange rates need be exchanged.

In a common commodity swap transaction, a first party agrees to pay to asecond party a fixed price per unit for a given number of units of acommodity (such as oil, electricity, corn or telecommunicationscapacity) per period over a certain number of periods in exchange forreceiving from the second party a market price (determined by previouslyestablished means) per unit for the same number of units per period andperiods. Again, market practice is for the parties to exchange the netof the two payments on each payment date, and the commodity itself neednot be exchanged.

More generally, such transactions typically may be characterized by oneor more underlyings (two in the swap examples above), a notional amount,and a payment provision. An underlying is a specified interest rate,security price, commodity price, foreign exchange rate, index of pricesor rates, or other variable. A notional amount is a number of currencyunits, shares, bushels, pounds, or other units specified in the contractof exchange. Settlement is determined by interaction of the notionalamount with the underlying, which may be multiplication, or a morecomplex formula. A payment provision specifies a fixed or determinablesettlement to be made if the underlying behaves in a specified manner.These and related terms as used herein are intended to be consistentwith Accounting for Derivative Instruments and Hedging Activities,Statement of Financial Accounting Standards No. 133 (FinancialAccounting Standards Board, 1998) (“FASB 133”).

By means of such exchanges of cash flows, parties may apportion andexchange risks, such as the risk of interest rate change, currencyvaluation change or commodity market price change.

Certain types of such exchanges, such as relatively short-term exchangesand/or those for which one party pays a lump sum, may be relativelyeasier to market than more complex exchanges. Some, including futuresand options, are sufficiently standardized to be traded on marketexchanges. Others, such as those for which both parties have structuredpayment terms and/or those with relatively longer terms (including swapssuch as interest rate, currency and commodity swaps), are typicallycustom-brokered arrangements.

For example, in the past parties seeking counterparties for a swaptransaction have found it necessary to use swap facilitators, in partdue to very significant search costs associated with finding potentialcounterparties who have matching needs. See, e.g., Kapner, et al., TheSwaps Handbook, p. 27, et seq. Investment banks, commercial banks,merchant banks, and independent broker/dealers traditionally havefulfilled the role of swap facilitators as swap brokers or dealers,taking for their efforts a commission or pricing differential betweenamounts bid and asked for particular transactions. It has been difficultor impossible for a party seeking a swap to locate a suitablecounterparty without incurring the costs of such facilitators.

In many instances, facilitators of swap and other relatively complexexchanges have acted as a counterparty in transactions when they havebeen unable to locate exactly matching counterparties for a desiredtransaction. In such instances, it has been difficult for facilitatorsto ensure that their own positions with respect to one or more suchexchanges (typically a portfolio) are hedged in a fully effectivemanner.

The present invention is directed to overcoming these and otherlimitations of existing methods and systems for facilitating exchange ofstructured cash flows by permitting counterparty-seeking parties tolocate and deal directly with each other, while preserving many of thebenefits formerly achieved only through intermediation by a third-partyswap facilitator, and creating new benefits for market participants. Thepresent invention is also directed to assisting third-party facilitatorsto more effectively intermediate exchanges of structured cash flows andact as counterparties in transactions while ensuring that thefacilitators' positions with respect to such exchanges are fully and/oreffectively hedged.

SUMMARY

In one aspect, the present invention comprises a system for determininga linear combination of structured cash flow exchanges having a netpresent value of substantially zero comprising: a digital informationstorage medium, the medium further comprising data representingprocessor instructions that operate on data representing a graph andproduce data representing the maximum flow for the graph.

In another aspect, the present invention comprises a system fordetermining a linear combination of structured cash flow exchangeshaving a net present value of substantially zero comprising a digitalinformation storage medium, the medium further comprising datarepresenting processor instructions that operate on data representing agraph and produce data representing the minimum cut of the graph.

The present invention further comprises a system for determining alinear combination of transactions, comprising a digital informationstorage medium, the medium further comprising data representingprocessor instructions for:

-   -   (A) adding a node representing a selected transaction to a        graph;    -   (B) for each node in the graph:        -   querying a transaction repository for each matching            transaction that is a partial match for the requirements of            the transaction represented by the node;        -   adding nodes representing each matching transaction to a            graph;        -   adding a directed arc from the node to each node            representing another transaction that is a partial match for            the requirements of the transaction represented by the node;    -   (C) repeating steps A and B until the graph contains nodes        representing every transaction in the transaction repository        that is a partial match for the requirements of a transaction        represented by a node in the graph    -   (D) determining the maximum flow on the graph.

In another aspect, the present invention comprises a method for matchingstructured cash flows for exchange comprising: receiving a firstexchange definition; retrieving from a database of one or more exchangedefinitions a plurality of exchange definitions comprising underlyingscompatible with the first exchange definition, each exchange definitionof the plurality comprising two or more underlyings, one or morenotional amounts or notional ranges, and one or more payment provisions;determining a linear combination of partial exchange definitions suchthat the net present value of the cumulative cash flow of the linearcombination of partial exchange definitions is substantially zero, eachpartial exchange definition comprising a fraction of a notional amountof the exchange definition ranging from zero to one; transmitting toeach party that proposed an exchange definition of the linearcombination information indicating the fraction of the party's exchangedefinition that comprises a partial exchange definition of the linearcombination.

In still another aspect, the present invention further comprises methodfor matching structured cash flows described above, wherein the partiesthat exchange definitions comprising the linear combination are notidentified to each other. The system further comprises the steps of:providing information of the linear combination of transactions to atleast one creditworthy party; receiving an acknowledgment that the atleast one creditworthy party is willing to act as counterparty in eachpartial transaction of the combination. The invention further comprisesthe method described above, wherein information of the linearcombination of transactions is provided to a plurality of creditworthyparties, and further comprising the step of: receiving from eachcreditworthy party information of the amount that the creditworthy partywould charge to act as a counterparty in each partial transaction of thecombination.

In addition, the invention comprises the above methods wherein theinformation of the amount that the creditworthy party would charge toact as a counterparty in each partial transaction of the combinationcomprises information of an amount specific to each party. In the abovemethod, the first transaction may represent an interest-bearing asset orliability and the combined notional amount of the combination ofexchanges may match the principal amount of the interest-bearing assetor liability. Further, one formula for computing net settlements may beused for each net settlement. In addition, the interest-bearing asset orliability may be not prepayable.

In another aspect, the present invention comprises a method fordetermining a set of offsetting structured cash flows for exchange,comprising: establishing in one or more memories a data structurecorresponding to a transaction graph for a collection of exchangedefinitions; the transaction graph having edges between exchangedefinitions having at least partially compatible terms; the at leastpartially compatible terms including at least one of: an underlying, astart date, an end date, a variance; determining a linear combination ofedges corresponding to a maximum notional amount for the graph withrespect to one or more exchange definitions.

In yet another aspect, the present invention comprises a method fordetermining a structured cash flow exchange, comprising the steps of:receiving from a first party one or more electronic signals, the signalsspecifying a first transaction; storing information of the exchangedefinition in a database; receiving from a second party one or moreelectronic signals, the signals specifying a proposed secondtransaction, each exchange definition comprising two or moreunderlyings, a notional amount or range, and a payment provision; basedon the proposed second transaction, querying the database; receivingfrom the database information of one or more transactions comprisingunderlyings compatible with the exchange definition; transmitting to theparty at least a portion of the information of one or more transactionscomprising underlyings compatible with the exchange definition, whereinthe information transmitted to the party does not include the identityof at least one other party.

In another aspect, the invention comprises a system for contracting toexchange structured cash flows comprising: a database comprising aplurality of exchange definitions, each exchange definition comprising:an indication of a first underlying, an indication of a secondunderlying, an indication of a notional amount; an indication of apayment provision defining cash flows to be paid or received withrespect to the notional amount and underlyings; a transaction monitorproviding atomicity, consistency, integrity and durability; a querysystem for searching the database for exchange definitions comprisingspecified underlyings. In response to a query, the query systempreferably returns information sufficient for a user to communicateanonymously with the parties whose exchange definitions comprise thespecified underlyings, but not sufficient to reveal the identities ofthose parties.

In another aspect, the invention comprises a system for determining anexchange of structured cash flows, comprising: digital memory programmedto further comprise: an abstract object class corresponding to a genericunderlying; a plurality of subclasses of the first object class, eachsubclass corresponding to a particular underlying.

In yet another aspect, the invention comprises a method for matchingstructured cash flows for exchange comprising: transmitting a firstexchange definition; receiving a linear combination of one or morepartial exchange definitions such that the net present value of thecumulative cash flow of the linear combination of partial exchangedefinitions is substantially zero, each partial exchange definitioncomprising a fraction of a notional amount of the exchange definitionranging from zero to one; communicating to each party that proposed anexchange definition of the combination information indicating thefraction of the party's exchange definition that comprises a partialexchange definition of the combination, without identifying the partiesto each other. In addition, the method preferably further comprises thesteps of: providing information of the linear combination oftransactions to at least one creditworthy party; receiving anacknowledgment that the at least one creditworthy party is willing toact as counterparty in each partial transaction of the combination.Information of the linear combination of transactions preferably isprovided to a plurality of creditworthy parties, and the methodpreferably further comprise the step of: receiving from eachcreditworthy party information of the amount that the creditworthy partywould charge to act as a counterparty in each partial transaction of thecombination. The information of the amount that the creditworthy partywould charge to act as a counterparty in each partial transaction of thecombination preferably comprises information of an amount specific toeach party. The first transaction preferably represents aninterest-bearing asset or liability and the combined notional amount ofthe combination of exchanges matches the principal amount of theinterest-bearing asset or liability. Further, preferably one formula forcomputing net settlements is used for each net settlement. Andpreferably the interest-bearing asset or liability is not prepayable.

In another aspect, the invention comprises a method for determining astructured cash flow exchange, comprising the steps of: transmitting oneor more electronic signals, the signals specifying a first exchangedefinition comprising two or more underlyings, a notional amount orrange, and a payment provision; receiving one or more electronic signalsspecifying one or more exchange definitions comprising underlyingscompatible with the first exchange definition, and informationsufficient to communicate with the parties proposing the one or moreexchange definitions without revealing the identity the partiesproposing the one or more exchange definitions.

DESCRIPTION OF FIGURES

FIG. 1 is a flow chart schematically illustrating system function in anexample preferred embodiment.

FIG. 2 is a flow chart schematically illustrating system function in anexample preferred embodiment.

FIG. 3 is a simplified schematic illustration of an example preferredexchange definition for a transactional embodiment in Universal ModelingLanguage (UML) in FIGS. 3 and 4.

FIG. 4 is a simplified schematic illustration of an example preferredacceptance provision component of an exchange definition for atransactional embodiment in Universal Modeling Language (UML) in FIGS. 3and 4.

FIG. 5 is a flow chart schematically illustrating system function in anexample preferred embodiment when a transaction is conditioned uponassumption of counterparty risk by a creditworthy entity.

FIG. 6 illustrates an example directed arc.

FIG. 7 illustrates paths in a graph.

FIG. 8 illustrates circuits in a graph.

FIG. 9 illustrates a transaction graph.

FIG. 10 describes the transactions from which the transaction graph ofFIG. 9 is generated.

FIG. 11 schematically illustrates the transaction graph of FIG. 9 recastas a maximal flow problem.

FIG. 12 schematically illustrates the results of step 0 of an examplepreferred embodiment.

FIG. 13 schematically illustrates the results of the first iterationthrough step 6 of an example preferred embodiment.

FIG. 14 schematically illustrates the results of the second iterationthrough step 6 of an example preferred embodiment.

FIG. 15 schematically illustrates the results of the third iterationthrough step 6 of an example preferred embodiment.

FIG. 16 schematically illustrates the results of the fourth iterationthrough step 6 of an example preferred embodiment.

FIG. 17 schematically illustrates the results of the first iterationthrough step 8 of an example preferred embodiment.

FIG. 18 schematically illustrates the results of the fifth iterationthrough step 3 of an example preferred embodiment.

FIG. 19 schematically illustrates the results of the fifth iterationthrough step 6 of an example preferred embodiment.

FIG. 20 schematically illustrates the results of the fifth iterationthrough step 10 of an example preferred embodiment.

FIG. 21 schematically illustrates the results at step 6 at theconclusion of an example preferred embodiment.

FIG. 22 schematically illustrates the underlying and notional amount forpayments between parties determined from a maximal notional flow withrespect to node 1 on the transaction diagram of FIG. 9 determined withthe method of the example preferred embodiment.

FIG. 23 schematically illustrates the underlying and notional amount forpayments between parties and a fully hedged substitute party determinedfrom FIG. 22.

FIG. 24 is a flow chart schematically illustrating system function in anexample preferred embodiment.

DESCRIPTION

The present invention comprises an electronic system for locatingmatching sets of cash flows specified by two or more parties, andassisting the parties to execute binding obligations to exchange cashflows. Using the system, a party (the “user” below) seeking to enterinto an agreement to exchange cash flows with one or more counterpartiesmay locate one or more potential counterparties seeking partially orexactly matching cash flows, evaluate whether to proceed with atransaction with the one or more potential counterparties, andconsummate a binding transaction. Payments are preferably made directlybetween the parties or through a paying agent. The system providespayment calculation and notification if desired.

In another aspect, the present invention comprises an electronic systemthrough which two or more users agree to enter into matched obligationswith a creditworthy third party. In such circumstances, the creditworthythird party becomes the counterparty of each user, and the users neednever be identified to each other. Because the users' obligations arematched, the creditworthy third party is hedged effectively in thetransaction.

In another aspect, the present invention comprises an electronic systemthrough which two or more users enter into matched obligations to eachother contingent upon assumption of counterparty risk by a creditworthythird party. Such an assumption may occur with the third party assubrogee, surety, guarantor, or through any other transfer of rights andobligations. Thus the creditworthy third party may act as acounterparty, guarantor or insurer of the users.

In a further aspect, the invention comprises a method and system throughwhich one or more entities contemplating an exchange of cash flows maydetermine whether transactions available to the one or more entities maybe combined to fully and/or effectively hedge the exchange.

FIGS. 1 and 2 show a flow chart schematically illustrating an examplepreferred embodiment. Referring to FIG. 1 at 101, the system receives anexchange definition from the user, partially or fully defining the cashflows the user seeks to pay and receive.

In a preferred embodiment, an exchange definition specifies at least anunderlying, a notional amount, and a payment provision. In addition, anexchange definition preferably specifies the units (e.g., currency) ofthe notional amount. Payment provisions preferably include cash flowdefinitions defining each cash flow to be paid or received with respectto the notional amount and underlying, and a schedule comprising asettlement date, start date, end date, and payment period, and a daycount (e.g., actual or 30-day months and actual or 360-day years).

In a preferred transactional embodiment, an exchange definition alsopreferably specifies an acceptance provision. An acceptance provisionspecifies conditions under which the user that specified the exchangedefinition will enter into an exchange specified by the exchangedefinition. A preferred acceptance provision specifies a minimum creditrating for potential counterparties, maximum acceptable variances forpayment and settlement schedules, an expiration date before which aprospective counterparty must consummate a transaction, and flagsindicating whether the user wishes the transaction to be conditionalupon insurance, guarantee, substitution, subrogation or other assumptionof obligations by a creditworthy third party. Other informationspecified by the acceptance provision may include an indication ofwhether price sensitivity or time sensitivity is of higher priority(e.g., whether the highest bidder, or first to meet requirements ispreferred).

A simplified example preferred exchange definition for a transactionalembodiment is schematically illustrated in Unified Modeling Language(UML) in FIGS. 3 and 4. Methods and fields unnecessary to the presentdescription, such as accessor methods for the fields shown, are omitted.

FIG. 3 schematically illustrates in UML a simplified class diagram foran exchange definition. An exchange definition in accordance with theexample is specified by an instance of the ExchangeDefinition Class.Each instance of the ExchangeDefinition class is associated with aninstance of the Party class specified by the Owner field, an instance ofthe PaymentProvision class specified by the PaymentProvision field, andan instance of the AcceptanceProvision class specified by theAcceptanceProvision field. The Party object specified by the Owner fieldindicates the party responsible for the exchange definition, typicallythe same party that specified the definition.

In this example preferred embodiment, the payment provision is specifiedby an instance of the PaymentProvision class. The examplePaymentProvision class class comprises a NotionalAmount field specifyingan instance of the NotionalAmount class, a PayUnderlying fieldspecifying an instance of the Underlying class, a ReceiveUnderlyingfield specifying an instance of the Underlying class, a PaySchedulefield specifying an instance of the Schedule class, a ReceiveSchedulefield specifying an instance of the Schedule class, a Counterparty fieldspecifying an instance of the Party class (and having a default ofnull), and a SettlementDate field specifying an instance of the DATEclass. The PaymentProvision also has a number of methods used todetermine the dates and amounts of the first, next and last payments andreceipts as shown in FIG. 3.

The Underlying class in the example preferred embodiment schematicallyillustrated in FIG. 3 is an abstract class, intended to be implementedby instances of concrete subclasses more closely related to particularcategories of underlying. Two such concrete subclasses are shown, theCommodity class and the CurrencyInterestRate class. These classes may befurther subclassed, or may delegate operations specific to subcategoriesof underlying (e.g., corn or telecommunications capacity) to associatedclasses. Instances of the Underlying class include a value for theMarketDataSource that is a Universal Resource Locator (URL) for currentvalues of the underlying, and a getCurrent method for use in retrievingvalues of the underlying necessary for cash flow calculations.

The Commodity subclass of the Underlying class schematically illustratedin FIG. 3 includes a Name field for specifying the name of thecommodity, and an Index field for specifying a particular source ormeasure of current value information for the commodity, and a getCurrentmethod overriding the getCurrent method of the parent class forretrieving the current price per unit for the commodity.

The CurrencyInterestRate subclass of the Underlying class schematicallyillustrated in FIG. 3 includes a Currency field for specifying thecurrency (e.g., U.S. Dollars) of the underlying, an InterestRateBasisfield for specifying the interest rate basis for the underlying (e.g.,U.S. Treasury 5 Year Bonds or London Interbank Offer Rate 3 month), aNotionalAmortization field for specifying a schedule for amortizing thenotional amount (e.g., bullet, sinking fund or mortgage-typeamortization), a PrincipalAmortization field for specifying a schedulefor actual exchange of principal (e.g., no actual exchange for a typicalinterest rate swap, a bullet exchange of the full notional amount for atypical currency swap), a spread for specifying an amount above or belowthe current value of the interest rate basis specified byInterestRateBasis at which payments will be calculated, and a Discountfield for specifying a discount from the notional amount of theunderlying (e.g., for zero coupon bond type exchanges). The getCurrentmethod returns the current value of the interest rate basis specified byInterestRateBasis.

The Security subclass of the Underlying class schematically illustratedin FIG. 3 is used to specify an arbitrary security as an underlying. TheSecurity class includes a Name field for specifying the name of thesecurity, a CUSIP field for specifying the CUSIP number of the security,a spread for specifying an amount above or below the value of thesecurity at which payments will be calculated, and a Discount field forspecifying a discount from the notional amount of the underlying. ThegetCurrent method returns the current value of the security specified bythe Security class

In this example preferred embodiment, an instance of the NotionalAmountclass is associated with an instance of the ExchangeDefinition classthrough an instance of the PaymentProvision class. The instance of theNotionalAmount class used to specify the notional amount for thetransaction specified by the ExchangeDefinition. The NotionalAmountclass includes an Amount field for specifying the notional amount, and aUnits field for specifying the units in which the Amount field isspecified.

Instances of the Schedule class are used to specify the schedule forpayments to and from the Owner of the ExchangeDefinition. The Scheduleclass includes a CalendarType field for specifying the type of calendarused for the schedule (e.g, 30 day months and 360 day years, actualmonths and 360 day years or actual months and actual years). Theschedule also includes a PaymentPeriod field for specifying the lengthof time between payments in accordance with the schedule. First and lastpayment dates are respectively specified by the FirstPaymentDate andLastPaymentDate fields of an instance of the Schedule class.

In the example preferred embodiment schematically illustrated in FIG. 3,an acceptance provision is specified by an instance of theAcceptanceProvision class. The AcceptanceProvision class includes aConditions field that specifies zero or more conditions that must befulfilled for a transaction in accordance with the ExchangeDefinition tobe acceptable to the user that specified the ExchangeDefinition. TheAcceptanceProvision class includes a checkAcceptable method fordetermining whether a particular ExchangeDefinition meets the conditionsspecified by an instance of the AcceptanceProvision class. TheAcceptanceProvision class also includes a Terms field that specifieszero or more terms of the transaction, and a getTerms method forretrieving the terms associated with an instance of theAcceptanceProvision class.

The AcceptanceProvision class of this example preferred embodiment isschematically illustrated in further detail in FIG. 4. Zero or moreinstances of the Condition class are specified by the Conditions fieldof the AcceptanceProvision class, and zero or more instances of the Termclass are specified by the Terms field of the AcceptanceProvision class.

The Condition class of the example preferred embodiment is an abstractbase class intended to be implemented by one or more concrete subclassesto produce classes for specifying particular categories of conditionsthat must be fulfilled for a transaction to be acceptable in accordancewith an ExchangeDefinition object. The Condition class includes acheckCondition method that should be implemented in any concretesubclass. The checkCondition method may be used to determine if aparticular ExchangeDefinition object meets the condition specified by aninstance of the Condition class. Five example subclasses of theCondition class are schematically illustrated in FIG. 4:SettlementDateOK, FirstPaymentDateOK, LastPaymentDateOK, CreditRatingOK,CounterpartyRiskAssumptionOK.

The SettlementDateOK subclass of the Condition class is used todetermine if an ExchangeDefinition specifies an acceptable settlementdate. A settlement date is acceptable if it falls with in an intervalspecified by the SettlementDateVariance field of the SettlementDateOKclass. The interval may be absolute (e.g., beginning Oct. 1, 1999 andending Oct. 31, 1999) or relative to the settlement date specified inthe Schedule associated with the ExchangeDefinition with which theSettlementDateOK instance is associated. The FirstPaymentDateOK andLastPaymentDateOK classes function similarly to the SettlementDateOKclass.

The CreditRatingOK subclass of the Condition class is used to determineif an ExchangeDefinition specifies an Owner having an acceptable creditrating. A credit rating is acceptable if it equals or exceeds the creditrating specified by the MinCreditRating field of the CreditRatingOKclass.

The CounterpartyRiskAssumptionOK subclass of the Condition class is usedto determine if an ExchangeDefinition specifies an acceptable form ofcounterparty risk assumption. A form of counterparty risk assumption isacceptable if it is listed in the acceptableTypes field of theCounterpartyRiskAssumptionOK class.

The Term class of the example preferred embodiment is an abstract baseclass intended to be implemented by one or more concrete subclasses toproduce classes for specifying particular categories of terms that mustbe met for a transaction to be acceptable in accordance with anExchangeDefinition object. Three example subclasses of the Term classare schematically illustrated in FIG. 4: OtherExchangesMade,CounterPartyRiskAssumption, and Expiration.

The OtherExchangesMade subclass of the Term class is used to specifyzero or more other ExchangeDefinition instances representingtransactions which must be consummated at the same time as thetransaction partially specified by the OtherExchangesMade instance. Forexample, if a party seeks to enter into an interest rate swap and acurrency swap at the same time, but will not enter into either unlessthe other is consummated, an OtherExchangesMade instance specifying theinterest rate swap ExchangeDefinition will be associated with theExchangeDefinition of the currency swap, and vice versa.

The CounterpartyRiskAssumption subclass of the Term class is used tospecify zero or more acceptable forms of counterparty risk assumption bya creditworthy third party.

The Expiration subclass of the Term class is used to specify a dateafter which the transaction specified by the ExchangeDefinition instancewith which the Expiration instance is associated will no longer beavailable.

The example preferred embodiment uses instances of theExchangeDefinition class to represent exchange definitions.

Referring to FIG. 1, at 102, the system searches one or more systemtransaction repositories for exchange definitions previously stored inthe system for one or more exchange definitions partially or fullymatching the requirements of the exchange definition of the user.

If one or more available exchange definitions partially or fully matchthe requirements of the user, the matching exchange definitions arereturned in a result dataset to the user 104. In addition to exchangedefinition information, the dataset preferably includes additionaldescriptive information about the parties whose exchange definitions areincluded in the result dataset. Such descriptive information may includethe credit rating, type of entity (e.g., financial institution,manufacturer, major dealer), location, number and/or dollar equivalentvolume of transactions sought and/or completed using the system, thenumber of times that the party has requested the identity of a userwithout completing the associated transaction, and system alias (ifany).

Preferably, the result dataset also includes sufficient informationabout the parties whose exchange definitions are included in the resultdataset for users to communicate anonymously with parties whose exchangedefinitions are included in the dataset, but not sufficient informationto reveal the identity of those parties. Thus, in a preferredembodiment, the system allows parties to make information available tousers sufficient to identify transactions potentially meeting the users'requirements and to provide users with an indication of the parties'reliability in completing transactions and counterparty credit risk, allwithout revealing the parties' identities. A preferred embodiment alsoprovides a facility for anonymous communication.

After receiving the dataset, the user reviews the dataset 105,preferably ranking the results in order of the relative desirability ofthe transactions described by the returned exchange definitions andassociated information in the result dataset.

If the user determines that one or more of the transactions described inthe result dataset are acceptable 106, the user causes the user'sexchange definition and associated descriptive information to becommunicated to the corresponding parties 107. In a preferredembodiment, the information communicated by the user to these potentialcounterparties mirrors the information provided to the user about thepotential counterparties in the result dataset. Thus, the informationprovided by the user to potential counterparties is sufficient to allowthe parties to communicate anonymously with the user, but is notsufficient to reveal the identify the user.

Like party information included in the result dataset received by theuser, the system preferably provides additional information about theuser to the potential counterparties. Such information may include thecredit rating, type of entity (e.g., financial institution,manufacturer, major dealer), location, number and/or dollar equivalentvolume of transactions sought and/or completed using the system, thenumber of times that the user has requested the identity of acounterparty without completing the associated transaction, and systemalias (if any). Thus, in a preferred embodiment, the system allows usersto make information available to potential counterparties sufficient toprovide potential counterparties with an indication of the user'sreliability in completing transactions and credit risk, all withoutrevealing the user's identity to the prospective counterparties.

After evaluating the information concerning a transaction from a user,one or more potential counterparties may respond in a timely mannerindicating an intention to proceed towards completing a transaction withthe user. The system determines whether sufficient counterparties tocomplete one or more (possibly alternative) transactions have indicatedan intention to proceed at 108. If so, the identities of the user andthe prospective counterparties in each possible transaction are revealedto the other prospective parties in that transaction 109. For example,in the case of a plurality of alternative counterparties for a two-partyexchange, the identity of each counterparty is preferably revealed tothe user, but not to the other alternative counterparties. If moreparties are required for a particular possible transaction, theidentities of the parties are revealed only to those necessary to thepossible transaction, and not to parties necessary to another possiblealternative transaction, unless the particular parties are necessary toboth. In a preferred embodiment, identification of the parties to eachother 109 is an atomic operation, so that no party's identity isrevealed to another unless that party's identity also is revealed.

In a preferred embodiment, when the user and potential counterpartiesare identified to each other, additional information is also provided.The particular additional information revealed with identity may dependon the information provided earlier in the process. For example, if thecredit rating of the parties was not made available earlier, the creditrating preferably is provided with the identity. In addition, detailedcontact, payment address, and other information sufficient to permit thegeneration of transaction documentation for execution by the partiesalso preferably is exchanged.

Referring now to FIG. 2, after the user and prospective counterpartiesare identified to each other, each party may indicate a wish to proceedtowards completing a transaction 201. Such an indication may indicate aconditional or unconditional intention to proceed. If an insufficientset of counterparties indicates an intention to proceed, the systemstores information 210 concerning the identity of the parties thatindicated a desire to proceed before the parties were identified to eachother 108 but failed to proceed after 201.

If one or more sets of parties sufficient to complete a transactionindicate an unconditional intention to proceed, the user may select oneor more sets of prospective counterparties to become actualcounterparties in a completed transaction 202. The system notifies theselected counterparties of the user's wish to proceed toward completingthe transaction 202 and also notifies non-selected prospectivecounterparties that the transaction will not be completed with them 203.

The system next generates documentation of the transaction frominformation provided by the parties and transaction documentationtemplates stored by the system 204. For example, in a typical swaptransaction, template objects are used to populate electronic copies ofInternational Swap Dealers Association (ISDA) standard swap agreementswith all information necessary to prepare the documents for execution bythe parties.

The generated transaction documentation is authenticated (e.g.,digitally signed) by the system and transmitted to the user and theselected counterparties for execution 205. In a preferred embodiment,users and counterparties have previously agreed to accept and be boundby documentation executed by digital signature.

The parties are (or previously have been) informed of a time limit forreceipt of executed transaction documentation. If complete executedtransaction documentation is received by the system within the timelimit, they are time-stamped, authenticated and permanently archived bythe system 207 and the parties are notified that a binding obligationhas been created 208 and provided with copies of the authenticatedtime-stamped executed documentation. Thereafter, at the option of theparties, the system may provide periodic notification of net paymentsdue under the obligation 209. The exchange definitions are removed fromthe transaction repository.

If complete executed transaction documentation is not received withinthe time limit, the parties are notified that the time limit has expiredwithout consummation of the transaction 211, and are given theopportunity to again attempt to consummate the transaction. If theparties indicate their intention to proceed 212, the system againgenerates documentation as before 204. Otherwise, the transaction isdiscontinued and information concerning the identity and failure of theparty or parties that failed to timely submit transaction documentationis stored by the system 210.

If one or more sets of parties sufficient to complete a transactionindicate an intention to proceed conditioned upon assumption ofcounterparty risk by a creditworthy entity, the system proceeds as willbe described with reference to FIG. 5. The condition of assumption ofcounterparty risk may be included in one or more exchange definitions asdescribed above, or communicated by one or more parties after the userand prospective counterparties are identified to each other. When thecondition is elected, the user and prospective counterparties are allnotified by the system of the condition.

If the form of counterparty risk assumption sought is insurance 302, theparty or parties seeking insurance define the insurance parameters(e.g., the policy amount) 303, and the insurance definition, exchangedefinitions and other party information is communicated to potentialinsurers as a request for quotation 304. Subsequently, quotations orrefusals are received by the system 305 and communicated to the parties.The system then determines whether the user and counterparties intend toproceed 201 and the system proceeds as described above.

If the form of counterparty risk assumption sought is a guaranty ofcounterparty performance 306, the exchange definitions and other partyinformation is communicated to potential guarantors 307. Subsequently,quotations or refusals are received by the system 305 and communicatedto the parties. The system then determines whether the user andcounterparties intend to proceed 201 and the system proceeds asdescribed above.

If the form of counterparty risk assumption sought is a substitution ofa creditworthy entity for the prospective counterparties 308, exchangedefinitions and party information are sent to available creditworthysubstitute parties 309. In this form of counterparty risk assumption,the user and prospective counterparties consummate transactions directlywith one or more creditworthy substitute parties, and not with eachother. Preferably, a single creditworthy substitute party is used, andthe substitute party becomes the counterparty for the user and each ofthe original prospective counterparties of the user. In this situation,the substitute party's transactions with the prospective counterpartiestaken together are a fully effective hedge for the substitute party'stransaction with the user. Significant accounting benefits under FASB133 may accrue to the substitute party as a result.

After quotations and/or refusals from creditworthy substitute partiesare received and communicated to the user and prospective counterparties310, the user and prospective counterparties select one or moresubstitute parties 311. New exchange definitions are generated by thesystem reflecting direct transactions between the user and the one ormore substitute parties, and each prospective counterparty and the oneor more substitute parties 312. The system then generates documentationfor these transactions 204 and proceeds as described above.

Returning again to FIG. 1, the search 102 may not return an exact match.If not, additional search options are available to the user. These maybe specified in a variety of ways by the user, and need not occurtogether, or in the order shown in FIG. 1. For example, in a preferredembodiment, a World Wide Web interface preferably is available andsimultaneously may present options 110, 111, 112, and/or 113 to the userin the form of links or buttons. Similarly, the system may receive theexchange definition object in 101 in one or more UML, CORBA, DCOM or RMImessage including additional fields specifying options 110, 111, 112and/or 113.

Option 110 provides the user the ability to search for transactionssimilar, but not identical to, the transaction described by the exchangedefinition received by the system 101. Similarity of transactions forpurposes of determining close matches preferably depends on searchand/or ranking or metric criteria which may be established by the user,and/or system default criteria. For example, a user may establish thatthe transactions nearest in notional amount or other specified aspect(e.g., first payment date, last payment date or payment period), orcombination of specified aspects be returned to the user. The userfurther may establish that, for example, only those transactions withinten percent (based on the established criteria) of the transactiondescribed by the exchange definition received by the system are to bereturned in a dataset. In another example, the user may establish thatonly the 20 most similar transactions based on the established criteriaare to be returned.

A ranking or metric is preferably provided or derivable for exchangedefinition data types that otherwise are unquantified. For example, forpurposes of similarity comparisons, fixed interest rates may be assigneda base numeric value of 0, and floating interest rates may be assigned abase numeric value of 10000. Added to these base values may be a numericvalue of 0 for fixed Treasury interest rates, and 0 for LIBOR floatinginterest rates, and the number of months of the term of each interestrate. Thus, the 30-year Treasury Bond interest rate would have anassociated numeric index of 360, and six-month LIBOR would have anassociated numeric index of 10006. Nearly any index facilitating rankingor distance comparisons between different values of a data type (such asalphabetical ordering) may be substituted for this example.

After reviewing and/or ranking a set of close matches 105, the userdetermines if any transactions are acceptable 106. If so, then the userproceeds as described above by providing terms and user information toparties who have specified acceptable transactions 107. If not, the usermay determine whether to make a counteroffer to one of the transactionsdescribed in the result dataset 117. If the user determines to make acounteroffer, the user creates a new exchange definition or edits onefrom the result dataset, selects parties from the result dataset toreceive the counteroffer, and provides the counteroffer information andadditional user information to the selected potential counterparties107.

Another option available to users is to post an exchange definition tothe system 112. Posting an exchange definition causes the user'sexchange definition to be added to the system transaction repositoryafter which the exchange definition becomes available for searching byother users.

Another option available to users is to monitor the system for newlyposted exchange definitions matching the user's exchange definition 113.When a new exchange definition matching the user's search definition isadded to the system, the system causes the user to be notified. The userspecifies whether to monitor exact matches for the exchange definition,or close matches.

Another option available to users is to request that the system attemptto synthesize an exchange matching the user's exchange definition bycombining proposed exchanges available on the system. The system may beused to determine a collection of transactions that, taken together,form a closed set of obligations that offset each other. The method usedby the system may be best explained with the aid of FIGS. 6-21. FIGS.6-21 schematically depict transactions as nodes in a transaction graph.Each node is arbitrarily labeled for convenience with a unique number.Each node is connected with one or more arrows, referred to as directedarcs, to other nodes representing other transactions.

As shown in FIG. 6, a directed arc may be specified by the ordered pair(i,j) wherein i represents the number of the label of the node fromwhich the directed arc points, and j represents the number of the labelof the node to which the directed arc points. A “path” is a sequence ofarcs {(i₀,i₁), (i₁,i₂), . . . , (i_(p-1),i_(p))} in which the initialnode of each arc is the same as the terminal node of each preceding arcin the sequence and i₀, . . . i_(p) are all distinct nodes. Each arc inthe path is thus directed away from i₀ and toward i_(p). For exampleFIG. 7 includes paths {(1,2), (2,3)} and {(1,2), (2,4), (4,5), (5,6)}and subpaths thereof. A “circuit” is a closed path; i.e., a path fromsome node i₀ to i_(p) together with the arc (i_(p),i₀). FIG. 8 shows anexample graph containing one circuit, {(1,2), (2,4), (4,5), (5,6),(6,1)}. The terminology used herein is intended to be consistent withthat of Bazaraa, et al., Linear Programming and Network Flows (Wiley,1990), which is incorporated herein by reference.

Transactions available on the system of the present invention may beconceptualized as a transaction graph such as the example shown in FIG.9. In such a transaction graph, a directed arc between a first node anda second node signifies that the second node represents a transactionthat specifies receiving at least a portion of a cash flow that thetransaction represented by the first node specifies paying.

A transaction graph may be constructed by adding a node for eachtransaction available on the system, and a directed arc from the node toeach node representing another transaction that is a partial match forthe requirements of the current transaction. For example, for a givennode a directed arc may be added from the given node to each noderepresenting another transaction that: (i) is of a counterparty meetingthe minimum credit rating requirements of the current transaction; (ii)states a notional amount in the same units; (iii) specifies receiving acash flow that is based on an underlying compatible with the underlyingof the cash flow to be paid for the given node; (iv) is on a schedule(including start date, end date and settlement date) within acceptablevariances of the current transaction.

The example transaction graph of FIG. 9 is generated from transactionsdescribed in more detail in FIG. 10. Each row of the table in FIG. 10describes a cash flow to be paid or received for each node in FIG. 9.The numbers in the column labeled “#” of FIG. 10 correspond to the nodenumbers shown in the circular node representations of FIG. 9. The columnlabeled “P/R” indicates whether the row describes the cash flow to bepaid (P) or received (R) by the corresponding transaction.The“Settlement Date Variance,” “Start Date Variance,” and “End DateVariance” columns indicate acceptable variances in days before and afterthe corresponding date. Thus, a settlement date variance of (−30, 0)indicates that acceptable settlement dates may be up to 30 days prior tothe specified date, but not later. The “Cal.” column indicates whetherdays are counted on an actual month/actual year (A/A) basis, a 30 daymonth/360 day year (30/360) basis, or an actual month/360 day year(A/360) basis.

As shown in the FIG. 10, node 1 represents a transaction specifying apayment on an underlying of LIBOR 3 month interest rate and a notionalamount of twelve million U.S. Dollars. The node 1 transaction specifiesa settlement date within the period beginning 30 days prior to Oct. 1,1999 and ending 30 days after Oct. 1, 1999, as indicated by the“Settlement Date” and “Settlement Date Variance” columns. The node 1transaction also specifies a start date for payments within the periodbeginning 30 days prior to Oct. 15, 1999 and ending 30 days after Oct.15, 1999, and an end date for payments within the period beginning 30days prior to Oct. 15, 2004 and ending 30 days after Oct. 15, 2004. Thepayment period is specified as 3 months, with no acceptable variance.The node 1 transaction also specifies a minimum credit rating for acounterparty of Aa, and a credit rating for the party corresponding tothe transaction represented by node 1 of Aa. The node 1 transaction alsospecifies an actual month/360 day year calendar, as indicated by “A/360”in the “Cal.” column.

Of the other nodes listed in FIG. 10, only node 2 represents atransaction specifying a cash flow to be received that: (i) is of acounterparty meeting the minimum credit rating requirements of thecurrent transaction; (ii) states a notional amount in the same units;(iii) specifies receiving a cash flow that is based on an underlyingcompatible with the underlying of the cash flow to be paid for the givennode; (iv) is on a schedule (including start date, end date andsettlement date) within acceptable variances of the current transaction.Thus a directed arc points from node 1 to node 2. Nodes 3, 4, 5, 6, 7and 9 specify different underlyings than node 1, and node 8 specifies anincompatible schedule (as does node 7), so no directed arcs point fromnode 1 to those nodes. Similarly, as shown by the arcs in FIG. 9, onlynodes 3 and 4 meet the partial requirements of node 2, only node 9 meetsthe partial requirements of node 4, only node 5 meets the partialrequirements of node 9, node 6 meets the partial requirements of bothnodes 5 and 3, and node 1 meets the partial requirements of node 6.Nodes 7 and node 8 are partial matches for each other.

Each circuit of FIG. 9 then represents a collection of transactionscomprising cash flows that, taken together, at least partially offseteach other. The maximum cash flow that may be offset by a circuit isdetermined by the minimum of the notional amounts specified by itsnodes. Three circuits are contained in FIG. 9—{(1,2), (2,3), (3,6),(6,1)}, which has a maximum circuit cash flow of $5 million; {(1,2),(2,4), (4,9), (9,5), (5,6), (6,1)}, which has a maximum circuit cashflow of $7.5 million; and {(7,8), (8,7)} which has a maximum circuitcash flow of $5 million.

Under some circumstances a transaction graph constructed as describedabove will contain circuits that cannot be accommodated by a singleschedule. This may be avoided by instead selecting a global schedule andadding only nodes to the transaction graph for transactions for whichthe global schedule is acceptable.

None of the circuits in FIG. 9 are alone sufficient to offset the full$12 million notional amount specified by node 1. However, a combinationof the two circuits passing through node 1 can fully satisfy the $12million notional amount specified by node 1. For example, by combining a$5 million notional amount over the circuit passing through node 3 witha $7 million notional amount over the circuit passing through node 4,the $12 million notional amount specified by node 1 may be achieved.Similarly, combining a $7.5 million notional amount over the circuitpassing through node 4 with a $4.5 million notional amount over thecircuit passing through node 3 will also accommodate the full $12million notional amount specified by node 1. In this example, acontinuum of intermediate solutions is also possible.

The question of whether, and to what degree, the notional amountspecified by a selected node may be accommodated by a combination ofswaps may be cast and solved as a maximal flow problem of linearprogramming by slight modification of the conceptualizationschematically exemplified in FIG. 9. Further, the technique may be usedto determine one or more combinations of available transactions thatmaximally accommodate the notional amount specified by the transactionrepresented by the selected node.

In this conceptualization, the selected node l for which maximalaccommodation is sought is regarded as comprising two separate nodes, acash flow source s and a cash flow sink m. For each directed edge (l,j)in the original graph, the recast graph contains a directed edge (s,j),and for each directed edge (i,l) in the original graph, the recast graphcontains a directed edge (i,m). FIG. 11 schematically illustrates thetransaction graph of FIG. 9 recast in this form.

Each directed edge (i,j) is regarded as having an associatedtransactional capacity u(i,j) equal to the minimum of the notionalamounts of nodes i and j. Each directed edge is further regarded ashaving an associated transactional amount x(i,j), representing anallocation of the cumulative notional amount of a combination of partialtransactions of which the nodes i and j are a part. The transactionalamount may be analogized to “flow” of a notional amount through thedirected edge (i,j). The problem of determining a set of notional flowsx(i,j) that maximize the notional flow from the source s to the sink mis equivalent to determining a set of offsetting partial swaptransactions that maximizes the notional amount offset with respect tothe node for which maximal accommodation is sought.

The maximal flow problem may be stated as follows:

maximize the flow f from s (or equivalently, to m)

subject to

${{\sum\limits_{j = 1}^{m}\; {x\left( {i,j} \right)}} - {\sum\limits_{k = 1}^{m}\; {x\left( {k,i} \right)}}} = \left\{ {{{f\mspace{14mu} {if}\mspace{14mu} i} = s};{{0\mspace{14mu} {if}\mspace{14mu} i} \neq 1};{{{- f}\mspace{14mu} {if}\mspace{14mu} i} = m}} \right\}$x(i, j) ≤ u(i, j)x(i, j) ≥ 0

where the sums and inequalities are taken over existing directed arcs inthe graph.

The maximal flow problem may also be characterized in terms of cut setsseparating node s from node m. If N represents the set of all nodes inthe graph, X is any set of nodes in the graph containing node s but notnode m, and Y=N−X, then the set of directed edges (X,Y)={(i,j) such thati is in X and j is in Y} is a cut-set separating node m from node s. Themaximal flow from s to m over the transaction graph is no greater thanthe capacity of any cut-set separating node m from node s, that is, thesum of the transactional capacities u(i,j) of the directed edges in anycut-set separating node m from node s. Further, the maximal possibleflow from s to m over the transaction graph is equal to the minimumcapacity of any cut-set separating s from m, known as a min-cut.

Excluding edges (s,2) and (6,m), the example shown in FIG. 11 contains 4min-cuts: {(2,3), (2,4)}, {(3,6), (4,9}, {(3,6), (2,4)} and {(2,3),(4,9)}. The maximal flow for the graph of FIG. 11 is thusu(3,6)+u(2,4)=u(2,3)+u(4,9)=u(2,3)+u(2,4)=u(3,6)+u(4,9)=$12.5 million.Since this capacity exceeds the notional amount of $12 million specifiedby the selected node, there exists one or more sets of notional flowsmeeting the requirements of the transaction of the selected node.

Having thus specified the problem, any of a number of linear programmingmethods may be applied to find one or more feasible sets of notionalflows maximizing the accommodation of a selected node in a transactionalgraph. The resulting set of flows x(i,j) represent the notional amountsof partial transactions between the counterparties corresponding to thenodes of the graph. Together these partial transactions accommodate thenotional amount of transaction specified by the selected node to themaximum degree possible given the set of transactions used to generatethe graph. Possible methods include the simplex method, the dual simplexmethod, the out-of-kilter algorithm, and others. However, methodsspecifically adapted to network flow problems are preferred, and resultin substantially faster performance.

In a system containing representations of a large number oftransactions, and particularly in such a system when parallel activitiesmay cause the unavailability of particular transactions on an ongoingbasis, it may be inconvenient or impractical to generate a completetransaction graph for the transactions available on the system. In apreferred embodiment, the system uses a method to find the maximalnotional flow for a selected node that does not require generation of acomplete transaction graph. Such a method is described below.

In one preferred method, a partial transactional graph G is constructedsequentially by initially adding the selected node, then repeatedlyquerying a system transaction repository for transactions partiallymatching transactions represented by nodes already present in the graph.A tag is associated with each node. The tag for a node j has the formt(j)=(+/−, i, d(j)) where d(j) indicates the amount of flow that can besent to node j from node s through the current graph with given flowswithout violating transactional capacity constraints. The +/− entry maytake the values + or −, and together with the entry i indicates theprevious node in the chain along which flow can be changed. A +i entryindicates flow will be added to directed arc (i,j) and a −i entryindicates that flow will be subtracted from arc (j,i).

The preferred method comprises the following steps:

-   -   (0)—Add node s to the partial graph G, and to the set NOARC    -   (1)—Erase all tags (i.e., set t(i)=null for all nodes i in G).    -   (2)—For each node i in NOARC:        -   (a) query the repository for all nodes j₁, . . . j_(n)            representing transactions that specify receiving cash flows            that partially match the cash flow payment specified by the            transaction represented by node i;        -   (b) remove node i from NOARC;        -   (c) add nodes j₁, . . . j_(n) to G and NOARC and directed            edges (i,j₁) . . . (i,j_(n)) to G.    -   (3)—Set t(s)=(−, infinity).    -   (4)—If node i has a tag (i.e., t(i) is not null), node j has no        tag (i.e., t(j) is null), and x(i,j)<u(i,j), then set        t(i,j)=(+i, d(j)) where d(j)=Minimum(d(i), u(i,j)−x(i,j)). If        node i has a tag and node j has no tag, and x(j,i)>0, then set        t(i,j)=(−i, d(j)) where d(j)=Minimum(d(i), x(j,i)).    -   (5)—Repeat step (4) until either node m has a tag or until no        more nodes can be tagged.    -   (6)—If node m is not tagged; and NOARC is empty, then DONE; if        node m is not tagged and NOARC is not empty, go to step (2).    -   (7)—If node m is tagged, starting with node m as the current        node:        -   (a)—if the tag of the current node i specifies the previous            node in the chain as +k, add d(m) to x(k,i);        -   (1)—if the tag of the current node i specifies the previous            node in the chain as −k, then subtract d(m) from x(i,k);        -   (2)—make node k the current node and repeat these steps            until node s is reached.    -   (8) Return to step 1.

Application of the example preferred embodiment to the transactionsdescribed in FIG. 10 with node 1 as the selected node are schematicallyillustrated in FIGS. 12-20.

In FIG. 12, the results of step 0 are shown. The selected node has beenrepresented as nodes s and m and node s has been added to the graph Gand the set NOARC.

In FIG. 13, the results of the first iteration of the method throughstep 6 are shown. In step 2, the system transaction repository was beenqueried for all transactions that specify receiving cash flows thatpartially match the cash flow payment specified by the transactionrepresented by the nodes in NOARC (node s). Specifically, the systemtransaction repository was queried for any transaction specifying a cashflow to be received that: (i) is of a counterparty meeting the minimumcredit rating requirements of the node 1 transaction; (ii) states anotional amount in the same units; (iii) specifies receiving a cash flowthat is based on an underlying compatible with the underlying of thecash flow to be paid for the node 1 transaction; (iv) is on a schedule(including start date, end date and settlement date) within acceptablevariances of the node 1 transaction. Only the transaction represented bynode 2 was returned. Node s was removed from NOARC and node 2 placed inNOARC. Node 2 and directed edge (s,2) were added to G and u(s,2) wasestablished as the minimum of the notional amounts specified by nodes sand 2, that is, $12 million.

Again referring to FIG. 13, the tag for node s was set to (−, infinity)in step 3, and since x(s, 2)=0 at this point, the tag for node 2 was setto (+s, d(2)) where d(2)=Minimum(d(s), u(s,2)−x(s,2))=Minimum(infinity,$12 M−0)=$12 M

FIG. 14 schematically illustrates the results of the second iterationthrough step 6. In step 2, the system transaction repository was againqueried for all transactions that specify receiving cash flows thatpartially match the cash flow payment specified by the transactionrepresented by the nodes in NOARC (node 2). Nodes 3 and 4 were returned.Nodes 3 and 4 and edges (2,3) and (3,4) were added to G, and thetransactional capacities of the edges were established as before asu(2,3)=$5 M and u(2,4)=$7.5 M. Also as above, t(3) is determined to be(+2, d(3)) where d(3)=Minimum(d(2), u(2,3)−x(2,3))=Minimum($12 M, $5M−0)=$5 M. Similarly d(4) is determined to be (+2, $7.5 M).

FIG. 15 illustrates the third iteration through step 6, and FIG. 16illustrates the fourth iteration through step 6. The analyses aresimilar to those of FIGS. 13 and 14.

Since node m was tagged when step 6, iteration 4 was reached, as shownin FIG. 16, steps 7 and 8 are executed by the system after the fourthiteration of step 6. The results are illustrated in FIG. 17. As shown inFIG. 17, d(m)=$5 M. Chaining backwards through the tagged nodes, theflows x(6,m), x(3,6), x(2,3) and x(s,2) are incremented by $5 M. Sincethese flows were zero prior to this step, the result is a $5 M value foreach flow.

The results of the fifth iteration through step 3 are schematicallyillustrated in FIG. 18. The tags of all nodes have been erased, andagain the system transaction repository is searched for transactionspartially matching transactions represented by nodes in NOARC. Only node6 is returned. Since node 6 is already in G, only the directed arc (5,6)is added to G.

The results of the fifth iteration through step 6 are schematicallyillustrated in FIG. 19. Since x(2,3)=u(2,3), node 3 is not tagged. Asdescribed above, tags are set as shown in the figure for nodes 2, 4, 5,6, 9, m.

Since node m was tagged when step 6, iteration 5 was reached, as shownin FIG. 19, steps 7 and 8 are again executed by the system after thefifth iteration of step 6. The results at step 10 are illustrated inFIG. 20. As shown in FIG. 20, d(m)=$7 M. Chaining backwards through thetagged nodes, the flows x(6,m), x(5,6), x(9,5), x(4,9), x(2,4) andx(s,2) are incremented by $7 M. Since flows x(6,m) and x(s,2) had valuesof $5 M prior to this step, the result is a $12 M value for flows x(6,m)and x(s,2). Since flows x(5,6), x(9,5), x(4,9) and x(2,4) were zeroprior to this step, the result is a $7 M value for each of these flows.

FIG. 21 shows the results of the sixth and final iteration through step6. Since x(s,2)=u(s,2), only node s is tagged. Since node m is nottagged, and NOARC is empty, the method terminates. Note that (s,2) is amin-cut for G, and for the transactional graph of FIG. 11. When themethod terminates, the set (L, L′) where L is the set of tagged nodesand L′ is G-L is a min-cut.

The foregoing method may be applied to a transaction graph constructedwith or without the selection of a global schedule as described above.If applied without a global schedule, circuits for which no singleschedule is acceptable may be avoided by adding the following step tothe method described above as follows.

-   -   (2) (d) truncate the schedule variances of the transactions        represented by nodes j₁, . . . j_(n) to exclude any portions not        compatible with the schedule definition of node i.        Thus, for example, when adding node 2 to G, the schedule        definition of transaction 2 in FIG. 10 would be truncated to a        settlement date of Oct. 15, 1999 with an acceptable variance of        (−30, 16), a start date of Nov. 1, 1999 with an acceptable        variance of (−30, 13) and an end date of Nov. 1, 2004 with an        acceptable variance of (−30, 13). Since during each iteration        nodes are added only for transactions specifying schedules        compatible with those represented by nodes in NOARC, no circuits        are formed for which no single schedule is acceptable.

When the method terminates, the notional flows x(i,j) determine a linearcombination of transactions specifying payments that, perhaps subject tominor adjustments and spreads, net to zero. If the combination oftransactions is consummated, each party to the combination will pay andreceive the cash flows specified by the exchange definitions theyspecified, but with notional amounts specified by x(i,j). If thetransactions are consummated directly between the parties, for eachx(i,j)>0 in G, the party that specified a transaction represented by anode j will be paid by the party that specified the transactionrepresented by node i. The terms will be those of the transaction eachparty specified, except that notional amount will be x(i,j), which maybe less than the amount originally specified. FIG. 22 schematicallyillustrates the underlying and notional amount for payments betweenparties determined from the x(i,j) in the example.

Because the combination of payments nets to zero, it is unnecessary forthe parties to make payments directly to each other. A paying agent maybe appointed to receive and pay out the payments according to thecombination transaction. Absent default by any party, the paying agentwill pay out the same amount in each payment period that it receives.

Moreover, because the linear combination of transactions is fullyhedged, the parties need not deal with each other at all. A substituteparty that is acceptable to all parties and willing to accept the creditrisk of the parties may act as the counterparty to each of the partiesof the combination. In this situation, the parties of the combinationneed never be identified to each other. Sufficient information forpotential substitute parties to adequately assess the credit risks ofacting as a substitute party is preferably provided to potentialsubstitute parties in this case. FIG. 23 schematically illustrates thepayments to and from a fully effectively hedged substitute partydetermined from linear combination of the example.

Referring again to FIG. 1, after determining the notional flows x(i,j)as described above, new exchange definitions are generated reflectingone or more multiparty transactions having notional amounts equal to thenonzero flows x(i,j) 116. The new exchange definitions and associatedparty information is provided to the user in a result dataset and theuser reviews the dataset 105 and proceeds as described above. Parties tosuch a synthetic transaction whose exchange definitions specifiednotional amounts larger than those reflected in the exchange definitionsof the completed transactions are given the opportunity to use thesystem to locate transactions matching the balance of their originalexchange definitions.

In a preferred embodiment, a synthetic combination is decomposed intoseparate multiparty transactions, one for each distinct circuit havingpositive notional flow in the solution graph G. Each such separatemultiparty transaction may then be treated separately by the system,although parties on paths occurring in more than one such circuit wouldbe provided with one transaction for each circuit on which they wererepresented.

System Architecture of an Exemplary Preferred Embodiment

Exchange definitions in a preferred embodiment are preferably instancesof objects which may be described in a standard notation. For example,in a preferred embodiment, exchange definitions could be expressed inaccordance with an object model translatable into Universal ModelingLanguage, Interface Definition Language for the Object ManagementGroup's (OMG's) Common Object Request Broker Architecture (CORBA) and/orJava Remote Method Interface (RMI) and/or Microsoft DistributedComponent Object Model (DCOM) Standardized General Markup Language(SGML) and/or Extensible Markup Language (UML). In one preferredembodiment, exchange definitions are translatable into UML in accordancewith the Financial Products Markup Language (FpML) specificationpublished by J.P. Morgan & Co. and PricewaterhouseCoopers.

The system transaction repository may be implemented as a database, suchas a relational or object-oriented database. In a preferred embodiment,the transaction repository is implemented using persistent objectoriented software components, and component transaction monitor, toprovide atomicity, consistency, integrity, durability (ACID) andfine-grained security to system operations in a highly distributedenvironment The transaction repository is preferably distributed, bothfor redundancy and fail-safety and to provide the ability for users withsubstantial system activities to operate, maintain and control access toportions of the transaction repository containing transactioninformation relating to their own activities. Queries to remote portionsof the transaction repository preferably may be mediated by a traderservice, such as that specified the OMG CORBA Trader specification.

In one preferred embodiment, the transaction repository and relatedsystem logic is implemented in accordance with the Sun MicrosystemsEnterprise Java Bean (EJB) specification. In particular, exchangedefinitions are stored in the system as Java objects in accordance withthe EntityBean class specified in the EJB specification.

Throughout this specification, portions of the system such as exchangedefinitions and other data elements and/or objects are described asbeing provided to other portions of the system (e.g., “passed”,“returned,” “received,” or “sent”). Unless specified, such descriptionsmay refer to transfer of information by reference, by value, or either.

Security

In a preferred embodiment, users of the system authorized to solicit orcommit to transactions are preregistered. The identity of users ispreferably authenticated by the system using standard public keyinfrastructure (PKI) methods, such as digital certificates conforming toITU X.509 issued to users by one or more certificate providers such asVerisign or Thawte Computing and verified by an SSL-enabled browser suchas Netscape. Preferably, all PKI private signature components used inthe system (by users and the servers) are stored in hardware securitymodules rated by the U.S. Government National Institute of StandardsFIPS-140-1 such as are available from Spyrus.

The system is preferably operated on a trusted operating system meetingNIST FIPS 151 standards, such as trusted Solaris from Sun Microsystems.Mandatory access control is used to restrict access to authorizedapplications.

1-24. (canceled)
 25. A method for determining a set of structured cashflows for exchange the method comprising: in an electronic systemcomprising one or more processors and one or more memories:establishing, via processor instruction, in the one or more processors adata structure corresponding to a graph having nodes corresponding to acollection of at least partial exchange definitions, a portion of thedata structure corresponding to at least one edge between the exchangedefinitions having at least partially compatible term; and determining,via processor instruction, data corresponding to a linear combination ofedges corresponding to a maximum notional amount for the graph withrespect to one or more exchange definitions.